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The NASA Space Communications Architecture Working Group (SCAWG) has recently 
been developing an integrated agency-wide space communications architecture in order to 
provide the necessary communication and navigation capabilities to support NASA’s new 
Exploration and Science Programs. A critical element of the space communications 
architecture is the end-to-end Data Networking Architecture, which must provide a wide 
range of services required for missions ranging from planetary rovers to human spaceflight, 
and from sub-orbital space to deep space. Requirements for a higher degree of user 
autonomy and interoperabflity between a variety of elements must be accommodated within 
an architecture that necessarily features minimum operational complexity. The architecture 
must also be scalable and evolvable to meet mission needs for the next 25 years. This paper 
will describe the recommended NASA Data Networking Architecture, present some of the 
rationale for the recommendations, and will illustrate an application of the architecture to 
example NASA missions. 


I. Introduction 

T HE National Aeronautics and Space Administration (NASA) has been developing a space communication and 
navigation architecture to support NASA Science and Exploration missions through the 2030 time frame. This 
work has been performed by the Space Communication Architecture Working Group (SCAWG), which is led by 
NASA Headquarters and includes members from across all of NASA. The initial SCAWG architecture was 
completed and approved by NASA in May 2006. This paper will focus on its Networking Architecture component. 

As illustrated in Figure 1, the Networking Architecture is one of four crosscutting architectures that overlay four 
physical elements of. the overall architecture. The Networking Architecture is required to support all NASA 
missions in all locations and operational scenarios and so the SCAWG Networking Architecture Team (NAT) had 
open representation from all NASA centers that have a stake in networking operations for previous, existing and 
future missions. The experience base of the participants therefore spanned everything from sub-orbital to deep 
space and robotic to human spaceflight missions. 
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Figure 1. Communications and Navigation Architectural Components 


XL The Recommended Networking Architecture 

The Networking Architecture is built upon a Security Architecture and a Spectrum Architecture. The Spectrum 
Architecture establishes the spectrum bands that will be used when implementing individual point to point data 
communication “hops” between space systems. Such hops are components of the end to end space data 
communications network - spanning both Earth and space assets - that interconnects space mission user 
applications. The Networking Architecture defines how the overall network containing those hops is structured in 
the context of the Security Architecture, which establishes how the information transiting that network is to be 
protected. Security services can be implemented at multiple points in the Networking Architecture. A Navigation 
Architecture defines how the various network elements are utilized in order to control the flight path of the space 
vehicle. The Security, Spectrum and Navigation components of the overall architecture are not further discussed 
here. 

A. Overview of the Networking Architecture 

In common with the terrestrial Internet, the underpinning of the Networking Architecture is a set of standard, low 
cost, layered data communications services that support end-to-end user applications. “On-ramps” are defined in the 
layered structure such that legacy systems, new services or diverse service providers can be easily integrated into the 
network. The Networking Architecture provides an open, flexible, and evoivable networked data communications 
sendees across all elements. This architecture enables mission selectable end-to-end communication options in 
accordance with established and evolving network policies that also govern the set of communication standards in 
use at any given time. 

The Networking Architecture presents a long term (25-40 year) vision and strategy for the evolution of NASA’s 
space communications systems, conceptually towards eventual provision of ubiquitous end-to-end user connectivity 
across the entire solar system. To accomplish this, the Network Architecture absorbs evolving terrestrial Internet 
technologies within its ground segment and extends them into and across space. The progressive and evolutionary 
build-up of standard infrastructure is a fundamental architectural tenet: it assumes that NASA will progressively 
invest in ground and flight data handling system designs that are engineered to be re-usable and that, over time, 
accrete into an “Interplanetary Interaef’ which spans the solar system in support of our missions of Science and 
Exploration. . 
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The Networking Architecture supports the full lifecycle of a space mission. It benefits mission planning by 
stimulating opportunities for interoperability with different organizations and by being easily scalable (up and down) 
to meet variable mission loading. It benefits the development, test and launch phases by reducing costs via re-use of 
common hardware and software infrastructure. It benefits the mission operations phase by enabling increased 
automation and security, by fostering the use of standard commercial products, and by reducing the need for 
unnecessary redundancy and labor-intensive planning. It benefits its operational users by providing access to 
familiar network-based applications using robust and reliable communications services (even when intermediate 
nodes are not available). 

B. Driving Requirements on the Networking Architecture 

The Networking. Architecture is driven by a set of top-level requirements either taken from existing requirements 
documents or derived from analysis of NASA’s integrated mission set. The key driving requirements are: 

* Provide multi-mission data communication services for: 

o Legacy missions 
o New Science missions 
o New Exploration missions 

* Support internetworked space and ground elements 

* Provide data communication service “on-ramps” for future government and, potentially, commercial 
service providers 

♦ Accommodate both scheduled and unscheduled communications 

♦ Accommodate both continuous and intermittent connectivity 

• Provide service over space data links characterized by: 

o Both large and small signal propagation latencies 
o Both uni-directionality and bi-directionality 
o Both low and high bit error rates 

* Support data flows that: 

o Originate at arbitrary user locations on Earth and in space 

o Terminate at arbitraxy user locations or sets of user locations (i.e., multi-point delivery) on Earth 
and in space 

o Traverse N-hop transmission paths where N > 1 

* Support transmission of the following types of data: 

o Command 
o Telemetry 

o Files (including web pages) 
o Messages (e.g., electronic mail) 
o Voice 
o Video 
o Range safety 

• Provide the following qualities of data communication service (not necessarily in all combinations): 

o Isochrony 
o Reliability 

o Transmission order preservation 
o Timeliness 
o Priority 

• Provide data communication performance metrics and accountability 
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C. Scope of the Space Communications Network 


NASA’s jSpace Communications Network logically interconnects end users via a series of physical layer "hops" 
or transmissions, as shown in Figure 2. 



information Flow 


Figure 2: Network Connects End Users via Physical Layer “Hops” 

The individual hops connect adjacent elements of the architecture and feature: 

• Terrestrial links connecting users to control centers, users to ground stations, or control centers to ground 
stations. 

• In-space links connecting ground stations to remote user vehicles, ground stations to relays, relays to relays, 
relays to remote user vehicles, remote vehicles to remote vehicles, or interconnecting end systems within 
remote vehicles. 

Information exchange between users flows logically (dashed lines) from source to destination independent of the 
underlying network structure. This flow is either wholly on Earth, between Earth and space, or wholly in-space. 
Although most transfers are between a single source and a single destination, the architecture supports point-to- 
multipoint (single source, multiple destinations) delivery where required. 

D. Layered Service Architecture 

In accordance with modem practices, user information exchange within the Networking Architecture is achieved 
by drawing upon a stack of “layered” services (Figure 3). Within a layered architecture, peer functions that exchange 
information across a data communications path are organized so that they provide a standard service to the layer 
above and draw upon standard service(s) from the layer below. As long as the service interfaces are preserved, an 
individual layer can be easily replaced as technology and mission requirements evolve. 

Peer functions at the sending and receiving ends of a layer exchange information across the network using a 
standardized dialog known as a data communications protocol. The protocol is represented by the ‘13118 on the wire” 
and it is the standardized mechanism by which senders and receivers in different organizations achieve 
interoperability. Interoperability is defined in The IEEE Standard Computer Dictionary as “the ability of two or 
more systems or components to exchange information and to use the information that has been exchanged.” 

Note that some of the service layers may reside in the user end systems and some may reside in the supporting 
mission-independent communications systems. The Networking Architecture encompasses all layers independent of 
the implementing organization. 


5 Institute of Electrical and Electronics Engineers. !EEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer 
Glossaries. New York, NY: 1990. 


4 

American Institute of Aeronautics and Astronautics 





i 

/ End 
/ User \ 
/ ■ \ 


/End\ 

/ User \ 



1 ; 

~n 

User j 


User j 


Appfesian Lr 

J 

AppScgfion 




Communis ales K'if> 
Se reinafe 9i?d 
oflfie layer 


Layer (n ) _J. ; 


rsing mli-defined 
rvles {protocol} 


Layer(n-1) 




- — — - — 
Space Communications Path 


Figure 3. Network Architecture: A Stack of Layered Services 


E. Exposed Services 


The service layers within the Networking Architecture are constructed as a staircase (Figure 4), with multiple 
service access points (“on-ramps”) provided so that users can reach-down as needed to access the services of lower 
layers if they don’t need the service of a higher layer. 



Service Access Seivice Access 



Space Commurijcacions Patfi 


Figure 4. Service Access Points in the Network 
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The “on-ramps” enable several key capabilities: 


• Basic emergency commanding can be done by bypassing all but the most rudimentary communications 
services; 

• Legacy systems, which do not necessarily conform to all the standard service layers, may be accommodated; 
and, 

• Different organizations (e.g., future commercial providers) may “drop in” their services as a confederated 
contribution to the overall end-to-end network. 


F. Definition of Networking Layers 

The Networking Architecture follows international standard service layering conventions as embodied in the 
well-known Open Systems Interconnection (OSI) model, including its terrestrial Internet derivative which reduces 
the OSI model to five layers: 

• Application Services reside in the Application layer and provide common utilities in support of familiar user 
applications (File Transfer, Messaging, Web browsing, audio and video formatting, etc.). The Application 
Services (which are part of the Networking Architecture) sit directly below the user applications (which are 
not). 

• Transport layer services support user-selectable levels of end-to-end data transfer reliability. 

• Network layer services automatically route data between user applications. 

• Link layer sendees support structured data transfer through a single point-to-point hop. 

• Physical layer sendees support unstructured symbol transfer through a single point-to-point hop. 

The relationship between these layers when two end systems are separated by a single space link hop is shown in 
Figure 5. 



Figure 5. Definition of Networking Sendees 

The network comprises all of the devices that may participate in the transmission of data between two users of 
NASA's end-to-end data communications infrastructure. The Application service and Transport service are hosted 
within the user end systems, yet they are still part of the end-to-end Networking Architecture. These are network 
utilities that are provided to users. The Networking Architecture therefore embraces the spacecraft and the 
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supporting ground networks, including control centers. The Network, Link and Physical services are implemented 
as part of an underlying “core” of multi-mission service infrastructure. 


How these abstract networking services are allocated to physical mission elements varies. One example is shown 
in Figure 6. 



Figure 6. Example of Networking Services Allocated to Physical Elements 

In some current and many future mission configurations, end-to-end data transfer may involve multiple hops, 
with core services embedded within in-space relays. Figure 7 shows how layered services may be configured in a 
simple two-hop intermediate space relay data flow. 

The Physical and Link services can only be provided across a single hop. If it is desired to bridge either of them 
across the inbound and outbound sides of a relay so that they tunnel transparently through the relay, then a relay 
application must be provided for this purpose. This application may operate either in real-time or in a store-and- 
forward mode. Unless all inbound and outbound links are engmeeredto be homogeneous, this relay application may 
be complex. 

The Network service, by its layering, is inherently independent of the underlying heterogeneous Link and 
Physical layers. It is relatively easy to standardize and as such it may be readily located at key hops in the end-to- 
end path, such as in-space relays. 
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Figure 7. Layered Services in a Two-Hop Intermediate Space Relay Data Flow 

In such a relay architecture, data protection via “bulk encryption” of the channel is usually only feasible if the in- 
space relay simply transponds (via a “bent-pipe”) the physical symbol stream in real time between its input and 
output sides. Such a scheme is currently implemented by legacy systems such as Space Shuttle and the ISS, which 
use the TDRSS in pure bent-pipe mode. To implement a Link or Network relay using such a data protection scheme, 
the Physical layer encryptions) must be locally terminated. The Security Architecture allows bulk encryption of the 
channel for future systems, however, this is operationally complex. 

HI. Standardization Trade-Offs 

The Networking Architecture traded-off five different options for where best to standardize the service 
infrastructure. The options considered were: 

• At the Physical Layer (Bit/Symbol stream services only). 

• Up to the Link Layer, with access to a standard Physical layer. 

• Up to the Network Layer, with access to standard Link and Physical layers. 

• Up to the Transport Layer, with access to standard Network, Link and Physical layers. 

• Up to the Application Layer, with access to standard Transport, Network, Link and Physical layers. 

Figures of Merit (FOMs) were used to evaluate the options in order to support the recommendation The FOMS 
used in NASA-wide trade-offs were as follows: 

• Operational Efficiency: The proportion of mission operations activity that must be performed by humans 
over the entire mission lifecycle, regardless of location 

• Robustness: A compound FOM consisting of: (a) The ease with which additional elements can be added to 
a mission or mission set (scalability); (b) the ease with which new operational capabilities can be introduced 
into mission operations systems (evolvability); (c) the ease with which data paths through the network can 
be changed in response to changing mission requirements (adaptability); (d) the proportion of the 
operational time in which the network operates without error (reliability); (e) the ease with which errors can 
be remedied (maintainability); and (f) the proportion of wall clock time in which the network operates 
(availability). 
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* Infrastructure Capability: (Communication Infrastructure Development and Maintenance Efficiency): The 
ease with which mission functionality is developed and maintained over the entire mission lifecycle, at 
vehicle end user terminals (spacecraft, aircraft, etc.); at ground stations and relay points; and Earth end user 
terminals (control centers, science centers, test facilities). 

* Ease of Transition: The ease with which the option can be implemented within NASA, including the 
acquisition of new equipment, development of new technology, and training of mission operators. 

* Interoperability: The ease with which users are able to complete all negotiations required to achieve 
successful and secure communication of mission information among both NASA and non-NASA assets and 
facilities. 

* Resource Utilization: Total value of user data delivered, given fixed resources. These resources include 
link utilization, available memory, available power, visibility windows, and launch mass. 

The Operational Efficiency and Infrastructure Capability FOMs were scored based entirely on requirements. 
Half of the Robustness FOM factors were scored based on requirements. The Ease of Transition, Interoperability, 
and Resource Utilization plus half of the Robustness FOM factors were scored based on team consensus. The 
conclusions of the tradeoff scoring were as follows: 

• Standardization should reach at least to the Network layer, although the benefits of standardization continue 
to increase above this layer. The Network layer is the “thin waist” of interoperability. There are multiple 
choices for heterogeneity in the Transport and Application layers above it; multiple choices for 
heterogeneity in the Link and Physical layers below it; but a minimum requirement for interoperability is 
that these choices must converge in a homogenous Network layer. 

• In order to support Network layer standardization, standardization of the underlying Physical and Link 
layers is required when different organizations act as the termini for the individual data links in the end-to- 
end path. 

Detailed protocol selection tradeoffs were not performed by this study. The choice for a Network layer standard 
is assumed to be the Internet Protocol, IP. However, since the complete IP suite cannot be sustained across the 
entire Networking Architecture (which includes disconnected, highly asymmetric or long delay space 
communications), an enhanced version of Network service - such as Disruption Tolerant Networking (DTN ) 6 - 
should be developed to accommodate environments where the performance of the IP suite is inadequate. 

IV. Conclusion 

Following the acceptance of the initial recommendation for a Networking Architecture based on standardized, 
layered communications services, the NASA Space Communications Architecture Working Group has begun the 
next required phase in the development of the Networking Architecture. Standard protocols will be selected as 
options for each communications layer. The options will be accompanied with guidance for mission designers to 
assist in the selection based on the individual mission needs. This first set of standard protocol options will become 
the core of the NASA communications architecture and will continue to evolve as new protocols and new 
requirements evolve. 
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